QQ about this: as I understand it, it is not possible to have 2 SonataFlowPlatform CRs in the same namespace (I noticed a Duplicate error in the second CR status), right?
So this means that it won't be possible to run 2 RHDH Orchestrator instances in the same namespace:

Release "my-backstage-orchestrator-2" does not exist. Installing it now.
Error: rendered manifests contain a resource that already exists.
Unable to continue with install: SonataFlowPlatform "sonataflow-platform" in namespace "my-ns" exists and cannot be imported into the current release: invalid ownership metadata;
annotation validation error: key "meta.helm.sh/release-name" must equal "my-backstage-orchestrator-2": 
current value is "my-backstage-orchestrator-1"

The problem is that we've had some (valid IMO) use cases where the user had access to a single namespace and deployed 2 instances of RHDH with different version/settings. And I can imagine the same for the Orchestrator flavor.
If this is something that you already aware of, I guess this should be added as a noteworthy note in the README.
(Or, instead of letting Helm fail, maybe check if the resource already exists and skip its creation? In which case, there might be other questions, like what happens to the SonataFlowPlatform CR if I uninstall the first Release but keep the second one?)

So a couple of things:

1. Yes, only one sonataflowplatform can exist in each namespace, even if it's under a different name. I'll add a check to validate if it exists so the Duplicate resource won't be created.
2. I believe multiple instanced of backstage in the same namespace, using the same sonataflowplatform should be OK, as long as the backstage versions are the same. The reason for that is that sonataflowplatform is also versioned, and the orchestrator plugin needs compatibillity between the sonataflow version and the rhdh version. an rhdh deployment using a mis-matches SFP version or OSL version will definitely create issues. So different value-backstage is OK but not different version, I think.

Not sure if we should prohibit this behavior or just not support it

After playing with it some more, removing the first helm release will destroy the sonataflow resources for the other orchestrator instances that exist, and that is a problem...
I'm not sure how we can actually support multiple orchestrator installations in the same namespace

Okay, I think it is fine to call this out in the docs as a known limitation and leave it as it is for now. But instead of the current error from Helm which is not that clear at first sight, I would suggest, if not too much additional work, returning a better error message letting the user know about this unsupported scenario.

Returning an error upon a second SFP apply sounds good, though the users can always hack and simply create more rhdh+rchestrator instances, then reconfigure the SFP to point to whatever secret they want. Anyway, will document the recommended way.

I'll take this with sonataflow team and see if we can file RFE to support more than a single platform per namespace.

@rm3l is the requirement for having few RHDH instances in the same namespace a production use-case or for testing?

Not sure if this is something we should recommend in production or not. I've seen this so far in a discussion with one user, where they were deploying two versions of the Helm Chart in their namespace.
And this is a scenario I usually tend to also check on Dev Sandbox for example where I'm limited to a single namespace.
So it most probably makes sense for testing.

I do not think we should even consider it for production :) , even for testing it is not really clear for testing of what user would need several instances of RHDH in one namespace?
I do not think we offer any multi-RHDH-instance scenario?